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(57) Die Erfindung betrifft ein Verfahren zur Bereit- 
stellung eines authentischen elektronischen Zertifikats. 
Ihr liegt die Aufgabe zugrunde, ein Verfahren anzuge- 
ben, durch welches solche Zertifikate schnell und ko- 
stengunstig bereitgestellt werden konnen. 

Die Aufgabe wird durch eine Automatisierung der 
Verifikationsvorgange fur die zur Erzeugung verwende- 
ten Identitatsmerkmale eines das Zertifikat anfordern- 
den Nutzers gelost. Ein das Zertifikat generierender und 
in eine Public-Key-lnfrastruktur eingebundener Server 
greift dazu auf Identitatsmerkmale zuruck, welche in ei- 



nem in seinem Zugriff befindlichen Speicher auf der 
Grundlage eines bereits bestehenden, elektronisch ab- 
gebildeten Vertragsverhaltnisses gespeichert wurden 
und im Hinblick auf das bestehende Vertragsverhaltnis 
ais vertrauenswurdig eingestuft werden konnen. Ge- 
ma3 einer moglichen Ausgestaltung greift der Server 
mittels einer inversen RADIUS-Abfrage auf bei einem 
Internet Service Provider gespeicherte Vertragsdaten 
zu. 
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Beschreibung 

[0001] Die Erfindung betrifft ein Vertahren zur Bereit- 
stellung eines authentischen elektronischen Zertifikats, 
bei welchem das Zertifikat von einem Client unter Nut- 
zung einer elektronischen Verbindung bei einem Server 
angefordert werden kann, der Server das angeforderte 
Zertifikat automatisch generiert und es an den Client 
ubertragt. 

[0002] Mit der zunehmenden Verbreitung elektroni- 
scher Medien fur die Datenubertragung bzw. Datenfern- 
ubertragung, insbesondere mit der zunehmenden Nut- 
zung des Internet fur derartige Zwecke steigt der Bedarf 
an MoglichkeitenzurGewahrleistungderVertraulichkeit 
und der Authentizitat der ubertragenen Daten. Vertrau- 
liche Daten werden daher vor der Ubertragung mittels 
kryptographischer Verfahren verschlusselt. Dabei wer- 
den fur offene Systeme wie das Internet sogenannte 
asymmetrische Verschlusselungsverfahren bevorzugt, 
bei denen fur das Verschlusseln einer Nachricht (von 
Daten) ein anderer Schlussel eingesetzt wird als fur das 
Entschlusseln. Soweit der fur das Verschlusseln ver- 
wendete Schlussel ein offentlich bekannter Schlussel 
(Public Key) ist, spricht man in diesem Zusammenhang 
auch von Public-Key-Verfahren. Derjenige, der den of- 
fentlichen Schlussel bekannt gibt, kann dabei von einer 
Mehrzahl unterschiedlicher Absender Nachrichten er- 
halten, welche von alien Absendern mit dem offentli- 
chen Schlussel verschlusselt werden, aber nur durch 
den Empfanger mit seinem personlichen und geheimen 
Schlussel zu entschlusseln sind. Auf diese Weise ist die 
Vertraulichkeit der ubertragenen Nachrichten gewahr- 
leistet. Im Hinblick darauf, dass der Nutzer eines offe- 
nen Systems, in welchem er Daten mit anderen Nutzern 
austauscht, wechselnd Absender und Empfanger von 
Nachrichten ist, verfugt jeder Nutzer, der diese Daten 
vertraulich unter Nutzung des Public-Key-Verfahrens 
austauschen mochte, uber einen eigenen, den anderen 
Kommunikationspartner bekanntzugebenden offentli- 
chen Schlussel und uber mehrere dffentliche Schlussel 
anderer Nutzer sowie uber einen privaten Schlussel. 
Aus Performancegrunden werden zur Verschlusselung 
groBerer Nachrichten auch so genannte hybride Verfah- 
ren eingesetzt, bei denen die Nachricht selbst mit einem 
schnellen symmetrischen Verschlusselungsalgorith- 
mus (z.B. DES - siehe hierzu z.B. Beutelspacher, 
Schwenk, Wolfenstetter "Moderne Verfahren der Kryto- 
graphie", 3. Auflage Vieweg Verlag Wiesbaden 1999) 
verschlusselt wird, und dann nur der zum Entschlusseln 
benotigte symmetrische Schlussel mit dem offentlichen 
Schlussel des Empfangers bzw. mit den offentlichen 
Schlusseln der Empfanger verschlusselt und der Nach- 
richt beigefugt wird. 

[0003] Allerdings identif iziert der offentliche Schlussel 
allein seinen Nutzer, eine Applikation Oder einen Host 
noch nicht, d.h. der Empfanger der verschliisselten 
Nachricht hat keine Gewahr uber deren Authentizitat, er 
weiB zum Beispiel nicht, ob der vorgebliche Absender 



auch der tatsachliche ist. Urn auch hier Sicherheit zu 
schaffen, bedientman sich eines weiteren kryptographi- 
schen Mechanismus, der so genannten digitalen Signa- 
tur. Der Nutzer einer digitalen, auch als elektronische 

5 Unterschrift bezeichneten Signatur muss dabei bei de- 
nen, die spater signierte Nachrichten von ihm erhalten, 
einmalig Vertrauen in die Authentizitat dieser elektroni- 
schen Unterschrift schaffen. Entsprechend einer einfa- 
chen, einen so genannten out-of-band-Mechanismus 

10 nutzenden Variante ist die Vorgehensweise hierzu in et- 
wa die folgende: Der Nutzer der digitalen Signatur si- 
gniert einen Datensatz, der seinen offentlichen Schlus- 
sel, Identifikationsinformationen (z. B. seine E-Mail- 
Adresse) und einen kurzen Hashwert enthalt, mit sei- 

15 nem privaten Schlussel. Nach der Ubermittlung der In- 
formation ruft er den Empfanger an und gibt ihm telefo- 
nisch den verwendeten Hashwert durch. Sofern sich 
Sender und Empfanger kennen, kann dabei der Emp- 
fanger den Absender der Nachricht anhand seiner Stim- 

20 me identifizieren. Demzufolge kann er auch den Daten- 
satz, sofern dieser nach Entschliisselung mit dem of- 
fentlichen Schlussel den ihm zur Kenntnis gegebenen 
Hashwert enthalt, als authentisch erkennen und ihn ent- 
sprechend kennzeichnen. Kunftig kann er jede auf iden- 

25 tische Weise signierte Mitteilung des Empfangers als 
authentisch einstufen (nahere Einzelheiten hierzu siehe 
u. a. Beutelspacher, Schwenk, Wolfenstetter "Moderne 
Verfahren der Krytographie", 3. Auflage Vieweg Verlag 
Wiesbaden 1999). Problematisch ist es hierbei, dass 

30 zur Gewahrleistung der Authentizitat ein vergleichswei- 
se hoher Aufwand erforderlich ist. Wollten sich bei- 
spielsweise die Mitarbeiter einer Firma mit 1 .000 Mitar- 
beitern auf die beschriebene Weise gegenseitig authen- 
tisieren, miisste hierzu jeder Mitarbeiter zumindest ein- 

35 mal mit jedem anderen kommunizieren. Es waren dem- 
nach 999.000 Telefonate erforderlich. 
[0004] Eine Verbesserung der Situation ergibt sich bei 
der Verwendung so genannter Public-Key-lnfrastruktu- 
ren. Hier wird das Vertrauen, also die Authentizitat in 

*o einer baumformigen Struktur uber- bzw. vermittelt. Die 
Nutzer mussen lediglich Vertrauen in eine Zertifizie- 
rungseinrichtung und das von ihr bereitgestellte so ge- 
nannte Root-Zertifikat herstellen. Alle anderen Vertrau- 
ensbeziehungen der Nutzer untereinander lassen sich 

^5 dann aus diesem Root-Zertifikat ableiten. Nahere Ein- 
zelheiten hierzu siehe beispielsweise http://www.lo- 
gosec.de/zertifikate.htm. 

[0005] Bezogen auf das oben genannte Beispiel der 
Firma mit 1.000 Mitarbeitern waren hier noch etwa 

so 2.000 Verifikationen notig. Dazu miisste jeder der 1.000 
Mitarbeiter das Root-Zertifikat akzeptieren und an einer 
zentralen Stelle mussten die mit dem jeweiligen offent- 
lichen Schlussel verknupften Identifikationsdaten der 
Mitarbeiter uberpruft und im Erfolgsfall der Datensatz 

55 mit dem privaten Schlussel, welcherdem Root-Zertifikat 
zugeordnet ist, signiert werden. Ein solches von der 
zentralen Stelle signiertes Zertifikat wurde auf Grund 
der Vertrauensbeziehung zwischen den Nutzem und 
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der Zertifizierungsstelle die Authentizitat der Mitarbeiter 
untereinander belegen konnen. Das Zertifikat ist dabei 
mit einem eiektronischen Personalausweis vergleich- 
bar. Die Erstellung derartiger Zertifikate erfolgt vorzugs- 
weise nach dem X.509-Standard der ISO. Allerdings 
verursacht die Uberprufung der Identifikationsdaten 
durch die zentrale Stelle dabei aber immer noch einen 
betrachtlichen Aufwand. Bei der Verwendung eines out- 
of-band-Mechanismus mussten die Nutzer beispiels- 
weise zu ihrer Identifizierung ihren Personalausweis 
oder andere ihre Identitat belegende Nachweise vorte- 
gen. Dies ist fur den massenhaften Einsatz viel zu auf- 
wendig und letztlich auch zu teuer. 
[0006] Aufgabe der Erfindung ist es daher, ein Verfah- 
ren anzugeben, durch welches authentische elektroni- 
sche Zertifikate schnell und kostengunstig bereitgestellt 
werden konnen. Die Aufgabe wird durch ein Verfahren 
entsprechend dem Hauptanspruch gelost. Vorteilhafte 
Ausgestaltungen bzw. Weiterbildungen des erfindungs- 
gemaBen Verfahrens sind durch die Unteranspruche 
gegeben. 

[0007] GemaB der Erfindung wird das Zertifikat von 
einem Client unter Nutzung einer eiektronischen Verbin- 
dung bei einem in eine Public-Key-lnfrastruktur einge- 
bundenen Server einer Zertifizierungsstelle abgefor- 
dert, von diesem Server automatisch generiert und an 
den Client ubertragen. In erfindungswesentlicherWeise 
generiert dabei der Server das Zertifikat unter Nutzung 
von Identitatsmerkmalen, welche in seinem Speicher 
oder in Speichermedien, auf die er uber elektronische 
Verbindungen Zugriff hat, auf der Grundlage eines be- 
reits bestehenden, in dem Speicher oder den Speicher- 
medien elektronisch abgebildeten Vertragsverhaltnis- 
ses gespeichertsind. Diese Identitatsmerkmale sind im 
Hinblick auf das bestehende Vertragsverhaltnis als ver- 
trauenswurdig einzustufen. Auf Grund einer dem Auf- 
bau der Verbindung mit dem Server vorausgehenden 
Anmeldeprozedur, welche eine Voraussetzung fur den 
Aufbau der eiektronischen Verbindung vom Client zum 
Server darstellt, stehen die im Zugriff des das Zertifikat 
generierenden Servers befindlichen Identitatsmerkma- 
le auBerdem in einer zumindestvermeintlichen eindeu- 
tigen Zuordnung zu dem das Zertifikat mittels des Cli- 
ents abfordernden Nutzer. In diesem Zusammenhang 
soil die Formulierung einer vermeintlich eindeutigen Zu- 
ordnung lediglich zum Ausdruck bringen, dass naturlich 
auch an dieser Stelle Manipulationen nicht auszuschlie- 
Ben sind, und zwar dann, wenn beispielsweise der ei- 
gentliche Nutzer des Clients seine Zugangsdaten fur 
das Internet einem anderen Nutzer bekannt gibt bzw. 
uberlasst oder wenn sie widerrechtlich durch einen Drit- 
ten in Erfahrung gebracht und genutzt werden. Grund- 
satzlich ist jedoch davon auszugehen, dass auf Grund 
der Anmeldeprozedur zum Herstellen der Verbindung 
zwischen dem Client und dem Server vom Nutzer des 
Clients Angaben abgefordert bzw. Handlungsweisen 
verlangt werden, in deren Ergebnis die Eindeutigkeitder 
Zuordnung fur den angestrebten Zweck unterstellt wer- 



den kann . Der Kemgedanke der Erfindung liegt also dar- 
in, den bereits erwahnten aufwendigen out-of-band-Me- 
chanismus zur Uberprufung der Identitat des das Zerti- 
fikat anfordemden Nutzers durch den eiektronischen 

5 Ruckgriff auf ein bereits bestehendes Vertragsverhalt- 
nis zu ersetzen, in dessen Rahmen als authentisch an- 
zusehende Identitatsangaben des Nutzers als elektro- 
nische Abbildung des Vertragsverhaltnisses abgespei- 
chert wurden. Dem liegt die Uberlegung zugrunde, dass 

10 personengebundene Daten heute sowieso bereits in 
vielfaltigster und weiterverarbeitbarer Form elektro- 
nisch gespeichert werden, wobei dieser Speicherung in 
vielen Fallen eine Uberprufung auf Authentizitat voran- 
geht. Warum sollte man sich also dieser Tatsache nicht 

15 bedienen. Selbstverstandlich mussen technische und 
gegebenenfalls auch organisatorische Voraussetzun- 
gen fur den Zugriff auf diese Daten geschaffen werden. 
[0008] GemaB einer praxisrelevanten Anwendung 
des Verfahrens handelt es sich bei der eiektronischen 

20 Verbindung zwischen dem Server und dem Client urn 
eine IP-Verbindung. Eine Ausgestaltung des Verfahrens 
sieht nun vor, dass die dem Client (und damit seinem 
Nutzer) bei der Einwahi in das IP-Netz nach dem erfolg- 
reichen Durchlaufen einer hierzu ublichen Anmeldepro- 

25 zedur zugeteilte temporare IP-Adresse als zentraler 
technischer Rcferenzwert fur den Zugriff des das Zerti- 
fikat generierenden Servers auf die im Zuge der eiek- 
tronischen Abbildung des bereits angesprochenen be- 
stehenden Vertragsverhaltnisses gespeicherten Identi- 

30 tatsmerkmale dient. Entsprechend einer bevorzugten 
Ausfuhrungsformfurdie Verwendung im IP-Netz erfolgt 
dabei der Zugriff des Servers auf die Identitatsmerkmale 
unter Umkehr der bei der Einwahi des Clients in das 
IP-Netz fur die Zuweisung der temporaren IP-Adresse 

35 genutzten Remote Authentication DiaMn User Service- 
Abfrage (RADIUS-Abfrage). Dabei lost der Server die 
temporare IP-Adresse, unter der ihn der Client kontak- 
tiert hat, durch eine inverse RADjUS-Abfrage und eine 
sich anschlieBende Datenbankaofrage zu den elektro- 

40 nisch gespeicherten Identitatsmerkmalen und aufgrund 
des zwischen dem Nutzer und einem Internet Service 
Provider (ISP) bestehenden Vertragsverhaltnisses als 
authentisch anzusehenden Daten des Nutzers auf. Dies 
ist moglich, wenn entweder der ISP selbst auch als Zer- 

45 tifizierungsstelle auftritt und er demzufolge auch den 
Server zur Generierung der Zertifikate betreibt und so- 
mit unmittelbaren Zugriff auf die Vertragsdaten hat oder, 
wenn der ISP dem Server einer als allgemein vertrau- 
enswurdig anerkannten Zertifizierungsstelle diesen Zu- 

50 griff einraumt. 

[0009] Entsprechend einer moglichen Variante des 
Verfahrens erfolgt die Anmeldeprozedur, also die Ein- 
wahi in das IP-Netz uber den Server eines ISP, unter 
Nutzung der Password Authentication Protocol Metho- 
ds de (PAP), so dass der Server unter Anwendung der in- 
versen RADIUS-Abfrage aus der temporaren IP-Adres- 
se zuerst auf den Username und gegebenenfalls auf 
das Password des das Zertifikat anfordemden Nutzers 
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schlussfolgert und mittels der sich daran anschlieBen- 
den Datenbankabfrage die (authentischen) Identitats- 
merkmale des Nutzers erhalt. Da der Username zumin- 
dest im Verhaitnis zu dem entsprechenden ISP in der 
Regel eindeutig ist, genugt fur den Zugriff auf die Da- 
tenbank im Grunde der Username. Insoweit bezieht sich 
die Formulierung "gegebenenfails Password" auch in 
den Anspruchen auf moglicherweise in der Praxis an- 
zutreffende andere Gegebenheiten, bei denen die Ein- 
deutigkeit der Zuordnung erst durch die Kombination 
Username / Password gegeben sein konnte. Unter Ver- 
wendung dieser Identitatsmerkmale generiert der Ser- 
ver das Zertifikat, wobei dies in einer Abfolge mehrerer 
Verfahrensschritte und in einem Dialog mit dem Client 
im Wesentlichen wie folgt geschieht: Der Server gene- 
riert zunachst einen partiellen Zertifikats-Request (in 
der Regel eine HTML-Seite, welche die die Identitats- 
merkmale reprasentierenden Daten enthait und zur Ge- 
nerierung des endgultigen Requests herangezogen 
wird), den er an den Nutzer sendet. Dieser muss nun 
noch sein Schlusselpaar generieren (i.d.R. durch den 
Browser nach Drucken eines Buttons auf der HTML-Sei- 
te), den Identitatsmerkmalen den offentlichen Schlussel 
hinzufugen und das Ganze mit Hilfe des privaten 
Schlussels signieren. (Das Format eines solchen Re- 
quests wird z.B. im Standard PKCS#10 genauer spezi- 
fiziert: http://www.rsasecurity.com/rsalabs/pkcs/pkcs- 
10/index.html.) Dieser signierte Datensatz wird an den 
Server zuruckgesendet, der daraus schlieBlich das ei- 
gentliche Zertifikat (z.B. nach dem X.509-Standard) ge- 
neriert. Zum Gewinnen zusatzlicher Sicherheit kann es 
bei dieser Verfahrensweise vorgesehen werden, daB 
der Server vom Nutzer nochmals das Password abfragt, 
z.B. vor Generierung des Zertifikatsrequests oder aber 
zumindest vor der Ubermittlung des Zertifikats an den 
Client. 

[0010] Das erfindungsgemaBe Verfahren ist jedoch 
auch unter Verwendung anderer Authentisierungsvari- 
anten bzw. anderer Anmeldeprozeduren moglich. Bei 
der Durchfuhrung im IP-Netz ist hierbei vorzugsweise 
auch an die Verwendung des Challenge and Response 
Authentication P rotocol (CHAP) zu den ken . Hierbei wird 
ein ein Zertifikat abfordernder Nutzer bei der Einwahl 
mit seinem Usemamen von dem Server, bei welchem 
er sich einwahlt (also von dem Server eines Internetser- 
viceproviders, welcher nicht unbedingt mit dem zur Er- 
stellung des Zertifikat dienenden Servers identisch ist - 
Einwahlserver), aufgefordert, eine zufallige Zahl (Chal- 
lange) mit einem geheimen ihm zugewiesenen und dem 
Betreiber des Einwahlservers bekannten Schlussel zu 
verschliisseln und die Antwort an den Einwahlserver zu- 
ruckzusenden. Der Einwahlserver verschlusselt seiner- 
seits die gleiche Zahl mit dem geheimen Schlussel. Ent- 
spricht das dabei erhaltene Ergebnis der Antwort des 
Nutzers des Clients, war die Anmeldung erfolgreich. Im 
Ergebnis dieser RADIUS-Abfrage wird dann dem Nut- 
zer des Clients die temporare Internetadresse zugeteilt. 
Erst wenn dem Nutzer die temporare Internetadresse 



zugewiesen wurde, kann er sich im IP-Netz bewegen 
und eine Verbindung zu dem die Zertifikate bereitstel- 
lenden Server aufbauen. 

[0011] In umgekehrter Weise, in welcher dem Nutzer 

5 bzw. dem Client bei der RADIUS-Abfrage die temporare 
IP^dresse zugeteilt wurde, kann der das Zertifikat ge- 
nerierende Server bei einer Zertifikatsanforderung aus 
der dabei fur die Verbindung zu ihm verwendeten tem- 
poraren IP-Adresse den Usernamen des Nutzers ge- 

10 winnen und mit diesem mittels einer Datenbankabfrage 
auf die Identitatsmerkmale des Nutzers zugreifen. Auf 
Grund des bereits bestehenden Vertragsverhaltnisses 
zwischen dem Nutzer und dem ISP konnen dabei diese 
Merkmale als vertrauenswurdig (authentisch) angese- 

15 hen werden. Folglich kann der Server hieraus ein au- 
thentisches elektronisches Zertifikat erstellen und an 
den Client ubertragen. Auch bei der Anmeldung unter 
Nutzung von CHAP kann eine RADIUS-CHAP-Abfrage 
zur nochmaligen Authentifizierung des Nutzer erfolgen, 

20 bevor das bereits generierte Zertifikat vom Server an 
den Client ubermittelt wird. 

Je nach der Struktur im Hinblick auf die Organisation 
der Zertifizierungsstelle bzw. des den Zugang zum In- 
ternet ermoglichenden ISP (Internet-Service-Provider), 

25 aber unabhangig von der verwendeten Anmeldeproze- 
dur (PAP oder CHAP), kann es sich bei dem Server, wel- 
cher die Zertifikate generiert, urn denselben Server han- 
deln, welcher auch den Zugang zum Internet ermog- 
licht. In jedem Falle handelt es sich aber urn einen Ser- 

30 ver, der auf die Identitatsmerkmale des Nutzers, welche 
im Rahmen der elektronischen Abbildung seines Ver- 
tragsverhaltnisses mit dem ISP in einer Datenbank ab- 
gespeichert wurden, Zugang hat. 
Entsprechend einer vorteilhaften Weiterbildung des 

35 Verfahrens ist es vorgesehen, dass die Generierung ei- 
nes Zertifikats durch einen hierfur bestimmten Server 
erst dann erfolgt, wenn das elektronisch abgebildete 
Vertragsverhaltnis und die zu diesem Zweck abgespei- 
cherten Identitatsmerkmale bereits uber einen vorbe- 

40 stimmbaren Zeitraum in der Datenbank abgelegt sind. 
Im Beispiel des Vertragsverhaltnisses mit einem ISP 
konnte es also denkbar sein, den Daten ein Kennzei- 
chen zuzuordnen, durch welches sie erst nach ein oder 
zwei Abrechnungsperioden, in denen der ISP die anfal- 

45 Jenden Internetgebiihren beim Nutzer abgerechnet und 
dabei uber die Authentizitat des Nutzers auf Grund einer 
erfolgten Zahlung hdhere Sicherheit gewonnen hat, zur 
Erstellung eines Zertifikats zugelassen werden. In Fal- 
len, bei denen das Datum des Vertragsabschlusses so- 
so wieso erfasst und in der Datenbank gespeichert wird, 
bedarf es nicht einmal eines solchen zusatzlichen Merk- 
mals. Vielmehr muss der mit der Erzeugung des Zerti- 
fikats beauftragte Server nach dem Eingang der aus der 
Datenbank abgeforderten Nutzerangaben nur dieses 

55 Datum (iberpriifen und entsprechend des Ergebnisses 
eines Vergleichs mit einer voreingestellten zeitlichen 
Bedingung das Zertifikat generieren oder dessen Gene- 
rierung verweigern. Fur den Fachmann ist klar, dass ein 



7 



EP 1 244 270 A2 



8 



solches zusatzliches, praktisch einer Plausibilitatsab- 
frage entsprechendes Kriterium ohne weiteres unter 
Nutzung der (des) von den Servern gefuhrten internen 
Systemzeit (-datums) ausgewertet werden kann. 
[0012] Die Erf in dung soli nachfolgend nochmals an 
einem Beispiel verdeutlicht werden. 
[0013] Ein Intemetnutzer hat ein bestehendes Ver- 
tragsverhaltnis mit einem ISP. In einer Datenbank auf 
einem Server des ISP sind bestimmte Im Zusammen- 
hang mit dem Abschluss des Vertrages bei dem Nutzer 
erhobene Identitatsmerkmale abgespeichert. Diese 
werden durch die Einwahl des Nutzers in das Internet 
nach dem erfolgreichen Durchlaufen einer Anmeldepro- 
zedur zuganglich. Der Nutzer wird beispielsweise bei 
der Anmeldung, sofern diese nach der PAP-Methodeer- 
folgt, nach seinem Nutzernamen und dem Password 
gefragt. Im Zuge der RAD lUS-Abf rage wird schliefllich 
dem Client des Nutzers eine temporare Internetadresse 
zugeordnet. Der Nutzer baut nun von seinem Client aus 
eine Internet- Verbindung zu einem Server einer Zertifi- 
zierungsstelle auf und fordert dort ein elektronisches 
Zertifikat ab. Auf Grund dessen, dass dieser Server 
ebenfalls durch den ISP oder aber in seinem Auftrage 
betrieben wird, hat der Server Zugriff auf die RADI- 
US-Nutzerdaten und die Kundendatenbank des ISP. Ein 
solcher RADIUS-Nutzereintrag sieht beispielsweise wie 
folgt aus: 

user_x Password = "abcde", Caller-Id 
"00892225558" 

Ascend-Send-Auth = Send-Auth-PAP, 
Framed-Protocol = PPP, 
User-Service = Framed-User, 
Framed-Address = 141 .45.240.1 ., 
Framed-Netmask = 255.255.255,255, 
Ascend-Metric = 2, 
Framed-Routing = None, 
Ascend-ldle-Limit = 720, 
Ascend-Dial-Number = 00892225558 

[0014] Im Sinne einer inversen RADIUS-Abfrage lost 
der das Zertifikat generierende Server die temporare I n- 
ternetadresse (141.45.240.1.) zunachst zu Username 
(user_x) und gegebenenfalls zu Password (vorliegend 
"abcde") des Nutzers auf. Mit diesen Angaben kann er 
nun uber eine Datenbankabfrage bei der Datenbank, in 
welcher der ISP seine Kundendaten als elektronische 
Abbildung der mit den Kunden geschlossenen Vertrage 
hinterlegt hat, als Identitatsmerkmale des das Zertifikat 
anfordernden Nutzers abrufen. In Bezug auf die an den 
entsprechenden ISP vertraglich gebundenen Nutzer ist 
dabei durch den Usernamen bzw. die Kombination 
Username/Password eine eindeutige Zuordnung zu be- 
stimmten Kundendaten (Merkmalen) gegeben. Diese 
Merkmale, welche auf Grund des moglicherweise be- 
reits langer bestehenden Vertragsverhaltnisses zwi- 
schen dem Nutzer und dem ISP als authentisch einzu- 
stufen sind, nimmt der zur Bereitstellung des Zertifikats 



aufgeforderte Server zur Grundlage fur die Generierung 
desselben. Mittels einer Einweg-Hash-Funktion erzeugt 
er das entsprechende Zertifikat. Nach der Generierung 
des Zertifikats oder parallel dazu wird der Nutzer uber 

5 seinen Client durch den mit ihm in Verbindung stehen- 
den Server nochmals zur Eingabe von User-Name und 
Password aufgefordert. Werden diese Angaben korrekt 
an den Server ubermittelt, dann ubertragt dieser das 
den Nutzer eindeutig authentisierende elektronische 

10 Zertifikat an dessen Client. Der Nutzer verf ugt nun uber 
ein Zertifikat, das er einerseits zur authentischen Uber- 
mittlung seines offentlichen Schliissels an Dritte, und 
andererseits zum Nachweis der Authentizitat einer von 
ihm mit seinem privaten Schlussel generierten Signatur 

15 verwenden kann. Durch das Vertrauen, welches die 
Nutzer in die Zertifizierungsbehorde haben, die den die 
Zertifikate generierenden Server unterhalt, ergibt sich 
gleichzeitig das Vertrauen in die Authentizitat des je- 
weils verwendeten Zertifikats. 

20 

Patentanspriiche 

1. Verfahren zur Bereitstellung eines authentischen 
25 elektronischen Zertifikats, bei dem ein solches Zer- 
tifikat von einem Client unter Nutzung einer elektro- 
nischen Verbindung von einem in eine Public Key- 
Infrastruktur eingebundenen Server abgefordert, 
von dem Server automatisch generiert und an den 

30 Client ubertragen wird, wobei der Server das Zerti- 
fikat unter Nutzung von Identitatsmerkmalen gene- 
riert, welche in seinem Speicher oder in Speicher- 
medien, auf die er uber elektronische Verbindungen 
Zugriff hat, auf der Grundlage eines bestehenden, 

35 in dem Speicher oder den Speichermedien elektro- 
nisch abgebildeten Vertragsverhaltnisses gespei- 
chert und im Hinblick auf das bestehende Vertrags- 
verhaltnis als vertrauenswurdig (authentisch) ein- 
zustufen sind, sowie aufgrund einer der Verbindung 
mit dem Server vorangegangenen Anmeldeproze- 
dur als Voraussetzung fur den Aufbau dieser elek- 
tronischen Verbindungen durch den Client in einer 
zumindest vermeintlich eindeutigen Zuordnung zu 
einem das Zertifikat mittels des Clients abfordern- 

45 den Nutzer stehen. 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, dass es sich bei der elektronischen Ver- 
bindung zwischen dem Server und dem Client urn 

so eine IP-Verbindung handelt. 

3. Verfahren nach Anspruch 2, dadurch gekenn- 
zeichnet, dass die dem Client bei der Einwahl in 
das IP-Netz nach dem erfolgreichen Durchlaufen 

55 einer Anmeldeprozedur zugeteilte temporare 
IP-Adresse als zentraler technischer Referenzwert 
fur den Zugriff des das Zertifikat generierenden Ser- 
vers auf die im Zuge der elektronischen Abbildung 
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des bestehenden Vertragsverhaltnisses gespei- 
cherten Identitatsmerkmale dient. 

4. Verfahren nach Anspruch 3, dadurch gekenn- 
zeichnet, dass der Zugriff des Servers auf die Iden- 5 
trtatsmerkmale unter Umkehr der bei der Einwahl 
des Clients in das IP-Netz fur die Zuweisung der 
temporaren IP-Adresse genutzten Remote Authen- 
tication Dial-In User Service-Abf rage (RADIUS-Ab- 
frage) erfolgt, wobei der Server die temporare 10 
IP-Adresse, unter der er kontaktiert wurde, durch 
eine inverse RADIUS-Abfrage und eine sich an- 
schlieBende Datenbankabfrage zu den authenti- 
schen Daten des Nutzers hin auflost. 

15 

5. Verfahren nach Anspruch 3 oder 4, dadurch ge- 
kennzeichnet, dass die Anmeldung des den Client 
bedienenden Nutzers bei der Einwahl in das 
IP-Netz unter Verwendung der Password Authenti- 
cation Protocol-Methode (PAP) erfolgt und der das 20 
Zertifikat generierende Server, die dem Nutzer 
nach der Anmeldung zugeteilte temporare I P-Adres- 

se im Zuge der inversen RADIUS-Abfrage zunachst 
zu Username und gegebenenfalls Password auflost 
und unter Nutzung dieser Angaben Zugriff auf die 25 
in der Datenbank hinterlegten Identitatsmerkmale 
des Nutzers erhalt. 

6. Verfahren nach Anspruch 5, dadurch gekenn- 
zeichnet, dass der das Zertifikat generierende Ser- 30 
ver im Zuge der Generierung, jedoch zumindest vor 
der Ubertragung des Zertifikats an den Client, noch- 
mals das zur Einwahl in das IP-Netz und mit dem 
elektronisch abgebildeten Vertragsvertialtnis und 
dem Usernamen korrespondierende Password 35 
beim Nutzer abfordert. 

7. Verfahren nach Anspruch 3 Oder 4, dadurch ge- 
kennzeichnet, dass die Anmeldung des den Client 
bedienenden Nutzers bei der Einwahl in das 40 
IP-Netz unter Verwendung der Challenge and Re- 
spond Authentication Protocol-Methode (CHAP) 
erfolgt und der das Zertifikat generierende Server, 

die dem Nutzer nach der Anmeldung zugeteilte 
temporare IP-Adresse durch eine inverse RADI- 
US-Abfrage unter Nutzung der CHAP-Methode und 
eine sich anschlieBende Datenbankabfrage hin zu 
den durch die eiektronische Abbildung des Ver- 
tragsverhaltnisses zu einem internetserviceprovi- 
der (ISP) gespeicherten Identitatsmerkmalen des so 
Nutzers auflost. 

8. Verfahren nach Anspruch 7, dadurch gekenn- 
zeichnet, dass der das Zertifikat generierende Ser- 
ver den Nutzer im Zuge der Generierung, jedoch 55 
zumindest vor der Ubertragung des Zertifikats, 
nochmals mit einer CHAP-Abfrage uberpruft. 



9. Verfahren nach einem der Anspruche 1 bis 8, da- 
durch gekennzeichnet, dass die Generierung des 
Zertifikats erst nach einer bestimmten Zeit des Be- 
stehens des Vertragsverhaltnisses zugelassen 
wird. 



